Can one of the admins verify this patch?

@helje5 pulling this convo in from #327.

so custom(418) is equal to .teapot, but custom(418,”earl gray”) differs to custom(418,”whatever”) 🤔

are you stating that custom anything lhs/rhs should be cased out, I can see the motivation for that. It is still much shorter then long case statement. I will make change.

@tanner0101 I completely agree from a web perspective the HTTP code is all that matters not the text description as localization could very well cause problems there. I think this would alter the enum's current behavior though. Further, the refactor could probably be reduced to just the enum conforming to the interface.

I think what we have here is mimic the same as we had before. If we want to change this another PR should be done IMHO.

@swift-nio-bot test this please

@pedantix IMO using a closed enum in a open API is deeply flawed in the first place, as demonstrated by the teapot (apart from the SemVer major source incompatibility you introduce by adding a case, the ugliness of custom, and all the bugs revolving around the .custom pattern).
Wrt the specific question: yes, the reason must be ignored. Why? Because it is already is stripped by the parser! I.e. you don't actually get the original reason for "builtin codes" and hence can't know whether it matches some other reason you got.

What could be done is to group all the cases that return true to one, and have only one line that returns true, without resorting to a default case.

@Lukasa does the code in my PR not keep the current behavior? As I read it, there is an ever-growing number of cases that pattern matches on if custom compares stored values, if not compare match on equal symbols(which is the source of the growth) if not default to false. I may be missing a swift subtlety but my PR is not aimed at changing functionality just reducing growth. There is definitely a weakness with using a default case. As @BasThomas says all the true pairs could be reduced to a single case, I am not sure if this is any better in terms of readability.

Sorry, you're right. :)

@swift-nio-bot test this please

@pedantix thanks!

@normanmaurer @weissi @Lukasa thank you! -119 lines of code as a net gain I think is just cool. This project is so great to make use of thanks!!!